Optimization And Case Sharing Of Singapore’s Independent Cloud Servers Carrying High Concurrency During The E-commerce Promotion Period

1. background and goal definition

define clear goals before the promotion period: maximum concurrent online users, target rps (requests per second), maximum tolerated response time (such as p95 < 500ms) and acceptable error rate (<1%). for example: it is expected that there will be 10,000 concurrent users, with an average of 4 requests per person per minute, the target rps ≈ (10000*4)/60 ≈ 667 rps, and reserve 2 times the margin as the peak target ≈ 1400 rps.

2. resource and topology planning

select a singapore computer room instance (for example, cloud vendor ap-southeast-1), and estimate the number of front-end instances based on the target rps. experience: a single web instance with a medium cpu can steadily carry 100–300 rps. calculation: number of web instances required = peak rps / single instance load. plan load balancing (cloud lb or nginx reverse proxy), database master-slave, redis for session and cache, and independent static file hosting to cdn.

3. system layer (kernel/tcp) tuning steps

execute on each linux server (as root or sudo): edit /etc/sysctl.conf to append and take effect: net.core.somaxconn=65535 net.ipv4.tcp_tw_reuse=1 net.ipv4.ip_local_port_range=1024 65535 net.ipv4.tcp_fin_timeout=15 net.ipv4.tcp_max_syn_backlog=4096 execute command: sysctl -p . also adjust ulimit: set nofile to 65536 in /etc/security/limits.conf.

4. practical configuration of nginx and http layer

use nginx as a front-end or reverse proxy, key example (nginx.conf worker/process): worker_processes auto; events { worker_connections 65535; multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 15; client_max_body_size 20m; } enable gzip, cache static resources and configure upstream health checks. reload command: nginx -t && systemctl reload nginx .

5. application and php-fpm/backend thread pool tuning

if you use php-fpm, estimate the number of pm child processes based on memory: pm = dynamic; pm.max_children = floor((总内存- 系统内存)/(单php进程内存)) . increase pm.max_requests to avoid memory leaks. for java/node applications, set up appropriate heap/thread pools and connection pools (database connection pool, http client pool) to avoid establishing a new connection for each request.

6. deployment steps of caching strategy (redis/varnish/cdn)

all static resources are uploaded to cdn (multi-point distribution, check singapore pop). use multi-level caching for dynamic pages: 1) edge cdn caching can cache static pages with parameters; 2) varnish or nginx caches hot html; 3) redis serves as hot data and session storage. redis configuration example: enable rdb/aof depending on persistence requirements, maxmemory-policy volatile-lru, and set maxmemory appropriately. startup command example: redis-server /etc/redis/redis.conf .

7. database (mysql/postgres) practical optimization

master-slave replication is separated from reading and writing: the master library is responsible for writing, and the slave library is responsible for reading. examples of key parameters for mysql tuning: innodb_buffer_pool_size≈60–70% of physical memory; innodb_flush_log_at_trx_commit=2 can improve write performance (note the risks); max_connections is adjusted according to the connection pool configuration. build indexes and slow query logs (enable slow_query_log=1) and optimize sql one by one. deploy proxysql or haproxy to achieve transparent read-write separation.

8. stress testing and capacity verification steps

use jmeter/locust or k6 to do staged stress testing: first do a progressive saturation test to the target rps, and then do a peak impact test. example locust command: locust -f locustfile.py --headless -u 20000 -r 1000 --run-time 10m --host=https://shop.sg . monitor cpu, io, number of connections, and response codes, record bottlenecks, and repair them one by one before retesting.

9. automatic expansion and contraction and fault recovery solution

if the cloud vendor supports it, configure the automatic expansion group (min/max/policy) based on cpu/rps. traditional independent clouds can use self-made scripts combined with prometheus alertmanager to trigger new instances and automatically join nginx upstream (example: use ansible or terraform to automatically complete instance initialization and registration). write rollback scripts and health checks to ensure one-click rollback to a stable version.

10. faq: how to quickly verify whether the environment is ready before the promotion starts?

q: how to quickly verify 48 hours before the promotion? answer: perform three checks: 1) perform a full-link stress test to the expected peak value of 50%-100% and observe the error rate; 2) verify the cache hit rate (redis/edge cdn>80%); 3) practice automatic expansion and rollback scripts. prepare night duty and alerting strategies and notify operations/development call chain.

11. faq: what should i do if a database writing bottleneck occurs?

q: if the main database becomes a bottleneck, how to temporarily alleviate it? answer: immediately enable write queues or asynchronousization: change non-strongly consistent writes to background queues (kafka/rabbitmq), and downgrade deferrable statistics or log writes to batch tasks; at the same time, temporarily increase innodb_flush_log_at_trx_commit=2 and increase the main database resources or upgrade to a larger instance in the short term (horizontal/vertical expansion).

12. faq: how to quickly locate and handle a large number of 5xx on the day of promotion?

question: what is the first step when encountering large-scale 5xx? answer: the first step is to enable full-link logging and circuit breaker: 1) divert traffic to healthy instances in lb and cut off instances with high error rates; 2) check nginx error.log and back-end application logs to locate application code, database or network; 3) if it is a cache avalanche or database connection exhaustion, clear the cache first and restart the connection pool service; if necessary, enable read-only or current limiting policies (by ip or by user) to protect the core payment path.